本篇是故事一的「內化」篇。

本篇要回答：這五天的踩雷、查證、重現與理解，最後能收斂成哪一份可以重複使用的東西？

當時發生了什麼

把前四天排在一起看，故事一其實只發生了一件事，換了四種形態：

• Day 01：規格問題問好問滿，但要檢出什麼還沒人知道。
• Day 02：把利害關係人當轉接頭，沒有人明確承擔過任何風險決定。
• Day 03：用「可以嗎」把工程判斷退回給沒有技術脈絡的一方。
• Day 04：把不同抽象層的名詞排成選單，用選名詞代替回答場景。

四種形態共用同一個空洞：**系統應完成什麼結果，從頭到尾沒有被寫下來。**每一個技術動作局部看都認真、都專業，但它們服務的需求單是空白的——所有討論只是在替空白需求單上色。

空白需求單不是修辭。把當時的討論攤開成一張需求單就會看到：規格欄寫得滿滿，「要得到什麼結果」那一欄是空的。更諷刺的是，當時每個人都覺得進度很好——因為規格欄每天都有新東西可以填。

我原本怎麼判斷

五天前我會說：需求不清是客戶的問題，工程師的本分是把技術做對。

現在的版本是：需求不清時，工程師手上其實有一份具體的工作——把「不清」本身結構化。哪些已知、哪些未知、哪些假設在撐著目前的討論、誰該在什麼時候補上哪個決定。這份工作不需要等任何人授權就可以開始做。

我怎麼查證或重現

驗證一份模板有沒有用的方式，是拿它回頭套自己的踩雷現場。我用「當時現場實際掌握的資訊」把 Day 01 的 AOI 廠勘案例填進模板，結果是：九個欄位有七個填不出來，而填不出來的欄位剛好對應前四天每一個踩雷點。填不出來不是模板失敗，那正是模板要暴露的東西。

填寫結果如下（依去識別化後的專案經驗整理，填寫依據是當時現場實際掌握的資訊）：

今天留下什麼方法

第一份可重用產出——問題定義與工程建議模板：

# 問題定義與工程建議

## 1. 使用者與利害關係人
（角色、是否實際使用、決策權、承擔的風險、驗收責任）

## 2. 預期結果
（系統完成後，什麼事情會發生？用可觀察的外部結果描述，不用技術名詞）

## 3. 情境
- 正常流程：
- 邊界情境：
- 失敗情境：

## 4. 執行假設
（目前討論建立在哪些未經確認的假設上）

## 5. 已知限制
（空間、時程、預算、環境、法規、既有系統）

## 6. 候選方案與建議
（每案含：成立前提、主要優點、主要風險、改採替代方案的條件）

## 7. 驗收方式
（誰、用什麼方法、量測什麼指標、通過標準）

## 8. 待確認事項
（缺什麼資料、誰提供、期限）

## 9. 決策者與結果承擔者
（每一項風險決定：誰做的、何時做的、依據什麼）

使用原則只有一條：填不出來的欄位不准跳過，它就是下一個要去問清楚的問題。

第一種失效模式

還沒定義系統應完成什麼，就開始討論要用什麼完成。

這是本系列收集的第一種失效模式。它的可怕之處在於完全不像事故：現場每個人都在認真工作，每個技術問題都合理，每次討論都有產出——直到某一天要驗收，才發現沒有人說得出驗收什麼。

本篇收尾

技術都還沒選錯，專案卻已經走偏，因為我們先回答了工具問題，卻沒有先寫下要得到什麼結果。

故事一到此收束。下一個故事（Day 06 起）從需求層下到執行環境層：同一台電腦、同一份程式碼，IDE 與 Terminal 卻用著不同的 Python——It Works on My Machine 最經典的版本，受害者與加害者都是我自己。